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La pr^sente invention a pour objet uri systeme de generation 
5 automatique de codes optimises operationnels sur une plate-forme 
materielle predefinie comportant au molns on processeur, pour un 
domaine ^application predetermine, a partir de codes sources soumis par 
des utilisateurs (ces utilisateurs etant compris Ici au sens large et incluant 
des utilisateurs finaux, mais 6galement des programmeurs duplications 

10 ou des programmeurs systeme). 

Depuis I'origine de rinformatique, de nombreux travaux ont ete 
realises concernant les compilateurs. 

Le principe d f un compilateur est d'analyser un code source decrit 
dans un langage de haut niveau puis de generer son equivalent en code 

15 binaire pour la machine cible. En general ce processus est effectue 
statiquement avant I'execution. II existe aussi des interpreteurs mettant en 
oeuvre des technologies de compilation dynamique qui ont permis de lever 
cette derniere contrainte en offrant la possibility de generer le code au 
dernier moment lors de I'execution. 

20 Le compilateur est un element de la chaine de preparation des 

programmes. Le resultat de la compilation peut §tre complete par des 
procedures deja compilees et gener^es (compilation separee ou 
bibliotheques), liees statiquement au chargement ou dynamiquement a 
I'execution. 

25 Les compilateurs sont en general organises en trois phases : 

1- Generation de code intermediate : a partir du code source, le 
compilateur reconnait les idiomes et genere une forme abstraite 
independante du langage source, communement appelee langage 
intermediate, Ce langage est independant de la machine cible. 

30 2. Optimisation haut niveau : dans cette phase sont regroupees un 
certain nombre ^optimisations qui sont en general independantes de 
I'architscture cible : propagation de consta rites, reduction de- force, 
S/roressiorcr communBS... 0=5 vptirriteaucns correspondent en general 
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3. Generation de code et optimisation bas niveau ; dans cette phase sont 
realisees toutes les operations et optimisations propres & la machine 
cible : generation et selection des instructions, allocation de registres, 
ordonnancement des instructions, etc. 
5 Les qualites d'un compilateur sont non seulement liees a 

Tarchitecture cible (performance du code genere) mais aussi au langage 
source (plus ou moins facile a compiler) et a ses caracteristiques en tant 
que logiciel (robustesse, richesse des options, Vitesse d'execution, etc.). 
Sauf le cas particulier de la compilation dynamique, I'ensemble des 
10 trois phases ci-dessus doivent etre realisees avant I'execution et ce dans 
un temps raisonnable, ce qui limtte d'autant la complexity des algorithmes 
d'optimisation qui peuvent etre implements dans un compilateur. 

Une grande part de la recherche sur les compilateurs est done en 
premier lieu liee au choix et a (a definition du langage source de haut 
15 niveau. 

Les evolutions des compilateurs sont egalement liees aux evolutions 
de ['architecture des processeurs et plus pr6cisement aux modeles de # 
performance decrivant le comportement de ces architectures. Comme 
dans tout probleme d'optimisation, une difficulty importante est la ^ 

20 definition d'une fonction cout qui soit representative du temps d'execution. * 
Les premiers jeux destructions avaient des comportements tr£s l " 
. simples : le temps d'execution d'une sequence destructions s'obtenait 
tout simplement comme la somme des temps d'execution de chacune des 
instructions de la sequence. En consequence, le processus d'optimisation 

25 etait tres simple et la principale strategie d'optimisation consistait a reduire 
le nombre et la complexity des instructions g£nerees. 

L'apparition des premiers jeux ^instructions CISC ("Complex 
Instruction Set Computer") a I£gerement modifies la donne dans la mesure 
ou des instructions tres complexes devenaient disponibles. Le probleme 

30 d'optimisation devenait alors essentiellement un probleme de 
reconnaissance d'idiomes (« pattern matching »). Dans cette m§me 
categorie, on peut inclure les jeux ^instructions vectorielles et les 
vectoriseurs qui etaient capables de reconnaitre les boucles qui se 
pretaient directement a une generation de code vectoriel. Au besoin le 

35 code source pouvait aussi etre transforme pour faire apparaitre des 
structures de code vectoriel. 
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Une rupture dans les strategies ^optimisation est venue avec 
(Introduction des pipelines, evolution architecturale qui decoupe le 
traitement des instructions en plusieurs operations executees 
sequentiellement, a I'image d'une chaine d'assemblage dans une usine. 
5 Cette technique qui permet de superposer ['execution de plusieurs 
instructions a un instant donne am&iore sensiblement les performances 
des systemes, mais introduit des deviations importantes en cas de 
« rupture » de pipeline, suite par exemple a la presence destruction de 
branchement. Elle a ainsi mis fin a la predictibilite du comportement d'un 

10 code donne. Une autre rupture importante provient de Tutilisation des 
hierarchies memoires : Toptimisation devait alors s'appuyer sur devaluation 
fine d'une metrique tr&s particuliere : la localite (spatiale et temporelle). 
Cependant Interaction entre le processeur et le systeme memoire etant 
simple, le processus d'optimisation devait avoir pour principal objectif de 

15 minimiser le nombre de "miss" (echecs) car chaque echec rajoutait une 
penalite au temps d'execution. II faut noter cependant que la minimisation 
du nombre de "miss" etait delicate et essentiellement realisable pour des 
structures de code simple de type boucle. Cette difficulty d'estimation de 
maniere statique des proprietes de localite conduisit a utiliser des 

20 methodes d'optimisation par gestion des proflls : le code etait execute une 
premiere fois pour determiner precisement les proprietes de localite 
(construction d'un profil). Ce profil etait alors utilise dans une deuxieme 
passe pour effectuer les optimisations liees a Sexploitation de la localite. A 
ce niveau de complexity architecturale, il etait deja tres difficile de definir 

25 de maniere simple une strategie efficace d'optimisation. Plus exactement, 
il etait extremement delicat de savoir combiner differentes optimisations et 
ce meme sur des cas tres simples : il n'existait pas de mecanisme 
permettant de modeliser/prendre en compte de maniere efficace les 
performances. Cest dans ce cadre qu'ont ete developpees les techniques 

30 de compilation - iterative qui combinent execution et optimisation de 
maniere a generer le meilleur code possible. Plus precisement, la 
compilation iterative consiste en la miss en ceuvre- d'une boucle.de 
^iransformsHon coda-rnesurs de pOTvmisTius /statique on 
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tres eleve en temps de calcul et de mise au point de ces methodes 
.teratives a limit* leur champ duplication a I'optimisation de 
bibliotheques. 

Les architectures RISC ("Reduced Instruction Set Computer") qui 
ublisaient un jeu destructions simple et uniforme (a I'oppose du CISC) 
ont vu le jour vers le milieu des annees 80. Les premieres generations de 
processors RISC etaient tres limitees en termes de fonctionnalite et la 
qualrte du code genere (en particulier I'ordonnancement des instructions) 
devenait alors un facteur cle dans la course a la performance. De maniere 
tres s ,m.lair e/ les architectures VLIW ('Very Long Instruction Word") 
ut.Lsa.ent des techniques de compilation tout a fait semblables pou 
explo.ter au mieux le materiel. Ces deux architectures RISC et VLIW 
ava.ent toujours un modele de performance simple deterministe dans la 
mesure ou globalement les instructions s'executaient dans le meme ordre 
que le code du programme genere, ce qui simplifiait considerablement le 
comportement de ces architectures et par la-meme ie processus 
d opt.misat.on. Toutefois, tres rapidement ces architectures ont generalise 
I ubl.sat.on du pipeline et des caches memoire pour obtenir de meilleures 
performances (plus precisement, ceci a amene une ameliorabon des 
performances en moyenne et au detriment de la predictibilite) 

L'apparition des architectures superscalaires (capables d'executer 
P^eurs instrucbons par cyde) et surtout les mecanismes de traitemen 
dans le desordre ("Out of Order Processing") des Instructions ont rendu 
encore pius diffidles les processus d . optimisation des fKKlbnm J^ 

Plus s,multanement les hierarchies memoires ont evolue rapidement • le 
nombre de niveaux a augmente et surtout divers mecanismes permettant 
de gerer de maniere plus ou moins explicite les different caches (pre- 
chargement, gestion de priorite,...) ont fait leur apparition. L'ensemble de 
ces mecanismes a rendu le comportement de fractions de code meme 
tres s.mples (boucle avec acces a 2 ou 3 tableaux) extremement difficile et 
par la-meme impossible a optimiser en s'appuyant sur des modeles 
simples de performance. Cette situation n'a fait qu'empirer avec Cecart 
grand.ssant entre les performances des processeurs et celles des 
memoires. 
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Globalement, au cours des deux dernieres decennies, au niveau de 
('architecture des processeurs, la richesse en termes de fonctionnalites 
s'est considerablement accrue. Ainsi le nombre de registres a 
considerablement augmente : de 8 registres en standard sur !es 
5 architectures CISC, on est passe a 32 registres sur les architectures RISC 
et meme a plus de 80 registres sur les architectures superscalaires. Au 
premier abord on peut penser qu'augmenter le nombre de registres va 
simplifier I'optimisation. En pratique, revolution des memoires a rendu 
('utilisation des registres encore plus cruciate et sur ce probteme 

10 d ! allocation de registre, le cout des algorithmes efficaces d'allocation de 
registre a considerablement augmente car leur complexity est 
exponentielle en fonction du nombre de registres disponibles. 

En reponse a ces evolutions recentes, la technologie des 
compilateurs a peu evolue : le nombre d'optimisations mises en oeuvre a 

15 bien sOr augmente mais la capacite a definir une strategic globale 
d'optimisation n'a pas progress^ et a meme diminue. 

Enfin, une derni&re tendance est apparue avec la compilation 
"dynamique". Le principe est simple et attrayant : la compilation 
dynamique (ou encore specialisation a Pex&ution) consiste a effectuer des 

20 optimisations de code au dernier moment, c'est-a-dire a Texecution. Une 
sequence de code est adaptee ("specialisee") en fonction des donnees 
d'entree (contexte d'execution) d'un programme. Un mecanisme a 
Pexecution "examine" le comportement des programmes suivant la 
frequence d'execution des sequences ^instructions et decide ou non de 

25 mettre en oeuvre des versions optimisees pour un contexte d'execution 
precis. Ce type de mecanisme intrinsequement dynamique est limite a des 
techniques d ? optimisation peu. couteuses en temps de calcul pour leur 
mise en oeuvre car elles ne doivent pas penaliser I'execution des codes. 

On rappelle par ailleurs qu'une bibliotheque est un ensemble de 

30 procedures, representatif d l un domaine ou d ! une portion de ce domaine : 
les composants d'une bibliotheque doivent en fait correspondre a des 
procedures standard frequemrnent utilisees. Le concept de bibliotheque 
eft tras 3ncian- snterieur 3 la notion de compilstsurs ec c'sst un d=s 
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Les bibliotheques peuvent corresponds a differents niveaux 
d abstraction du plus simple au plus complique : BLAS 1 ("Basic Linear 
Algebra Subroutines Level I") est un ensemble d'operations tres simples 
portant sur des vecteurs mais permettant d'exprimer un grand nombre 
5 dalgorithmes classiques d'algebre lineaire. A I'autre extreme, UNPACK 
(resp. EISPACK) est un ensemble complet de procedures permettant la 
resolution de systemes lineaires (resp. le calcul de vecteurs propres et de 
valeurs propres). Un grand nombre de bibliotheques ont ete developpees 
et largement utilisees dans les domaines particuliers suivants • 
10 . Calcul scientiflque : BLAS1, BLAS2, BLAS3, BLAST, SPARSE BUS 
LINPACK, LAPACK, BLACS, PVM, MPI, etc. 

• Traitement de signal : FFTPACK, VSIPI, etc. 

• Graphique : DirectX, OpenGL 
Le fait que, dans un domaine d'applications donne, un certain 

nombre de bibliotheques aient ete definies et identifies traduit le fait cue 
ce domaine puisse §tre "synthetise". 

Le plus gros defaut des bibliotheques est cependant que leur 
foncdonnalite est tres limitee et qu'elles induisent une utilisation manuelle 

20 pro a cedu n re) eSSitent rmSe ^° n te C ° de S0UrCe d ' un a PP el ex P ,icite * 
Les premieres generations de bibliotheques (correspondant a des 
procedures simples et de petite taille) ont ete en general developpees a la 
ma.n en assembleur. Ceci est tres souvent reste le cas des que la 
performance est le critene majeur (sous reserve bien sQr que les 
procedures restent d'une taille raisonnable). 

Par contre, a la difference de la compilation qui est globalement un 
processus "en ligne" (les temps de compilation doivent rester moderes) 
I optimisation de bibliotheques est essentiellement un processus "hors 
connexion" et peut utiliser des methodes beaucoup plus gourmandes en 
temps de calcul. Ainsi la compilation iterative est un excellent outil 
d optimisation pour le developpement de bibliotheques mais qui ne peut 
ma heureusement etre utilise que pour des codes simples vu sa lourdeur 
d utilisation. 

. Dans le m§me ordre d'idee, la technologie de type "Automatic 
35 Tuning Lrner Algebra Software" permet de realiser une partre de 
lopbmisation (choix des bons parametres tels que tallies des blocs) 



25 



30 



1 er depot 



Malheureusement cette technique est d'utilisation tr6s restreinte car elle 
est tres dependante du type duplication considere (calcul sur des 
matrices denses, calculs caracterises par une tres forte localite 
temporelte). 

5 Les outils d'analyse de performance existants sont tres varies (en 

particulier en fonction de I'objectif recherche) : 

• Tests de performances (« benchmarks ») : ce sont des codes plus ou 
moins repr^sentatifs d'un domaine duplication et qui permettent de 
comparer les performances de diverses machines. 

10 • Simulateurs : ils permettent d'apprehender le comportement d'une 
architecture au niveau ie plus fin. Malheureusement ils sont tres 
couteux, delicats a developper, tres lents et pas necessairement fideles 
par rapport au processeur cible. 

• Modeles mathematiques : il s'agit de mettre en equation la 
15 performance de la machine. En general leur utilisation est 

extremement limitee et ils ne sont utiles que pour etudier differentes 
variantes simples autour d'un meme code tres simple. 

• Outils de controle/gestion de profits : ces outils permettent de 
recuperer (via des compteurs de materiel specialises) differentes 

20 informations relatives a Texecution d'un programme : nombre de 
cycles, nombre de miss, etc. 

On peut par ailieurs formuler les remarques suivantes : 

- Les tests de performance 6voluent peu et surtout sont devenus Tobjet 
d'enjeux commerciaux trap importants. Tres souvent, leur optimisation 

25 acharnee par les constructeurs fausse la portee et la validite des 
resultats obtenus. 

- Simulateurs : ('exploitation de leurs resultats (pour i'optimisation de 
code) devient de plus en plus difficile dans la mesure ou 1'architecture 
ciblee est devenue tres complexe. 

30 - Modeles mathematiques : ils evoluent peu et en dehors de Pusage local 
mentionne ci-dessus, ils sont inutilisables. Une des raisons en est que 
les bons outils mathematiques de modeiisation presupposent un 
comporterncTit "unrrormemBnt rnovenne", qui est loin d'etre le cas 
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distribution de I'activite au cours du temps ; ils ne permettent pas de 
correler code et comportement au niveau fin ; enfln, leur exploitation 
(comme dans le cas du simulates) est tres delicate, en raison 
notamment de la complexite de Tarchitecture ciblee. 
5 La presente invention vise a remedier aux inconvenient* pr«§cites et 

a permettre, pour une plate-forme materielle predefine comportant au 
moms un processeur, de g^nerer de facon automatique des codes 
optimises operationnels sur cette plate-forme pour un domaine 
duplication predetermine a partir de codes sources soumis par des 
10 uulisateurs. K 

De facon plus particuliere, I'invention vise a accroitre les 
performances de systemes informatiques de facon independante du choix 
du langage source et ceci pour des systemes mettant en ceuvre des 
processeurs dont I'architecture peut faire appel a des instructions simples 
ou complexes et qui peuvent comprendre un nombre plus ou moins 
important de registry d'unites fonctionnelles et de niveaux de cache 

L'mvention a egalement pour objet d'eviter les limitations de la 
couverture foncOonnelle des bibliotheques de programmes specialises et 
vise a creer un systeme de generation automatique de codes optimises 
pour un grand nombre de structures de code voisines, qui peuvent 
presenter differents niveaux de complexite. 

« ^ , bUt$ S ° nt attelntS ' conform ement a Hnvention, grace a un 
systeme de generation automatique de codes optimises operationnels sur 
une plate-forme materielle predefinie comportant au moins un processeur 
pour un domaine ^application predetermine a partir de codes sources 
soumts par des utilisateurs, caracterise en ce qu'il comprend des moyens 
de reception de sequences de codes symboliques dites sequences-etalons 
representatives du comportement dudit processeur en termes de 
performances, pour le domaine duplication predetermine ; des moyens 

m^S i0n ^ Para ^ eS ****** d£§finiS 4 Partir de ,a P'ate-forme 
matenelle predefine de son processeur et des sequences-etalons ■ des 
moyens de reception de parametres dynamiques egalement definis a 
partir de la plate-forme materielle predefinie, de son processeur et des 
sequences-etalons; un dispositif d'analyse pour etablir des regies 
d optimisation a partir de tests et de mesures de performances etablis a 
partir des sequences-etalons, des parametres statiques et des parametres 
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dynamiques ; un dispositif d'optimisation et generation de code recevant 
d'une part les s£quences-etalons et d'autre part les regies d'optimisation 
pour examiner les codes sources d'utilisateurs, detecter des boucles 
optimisables, decomposer en noyaux, assembler et injecter des codes 
5 pour delivrer des codes optimises ; et des moyens pour reinjecter dans les 
sequences-etalons des informations issues du dispositif de generation et 
optimisation de codes et relatives a des noyaux. 

De fagon plus particuliere, le dispositif d'anaiyse comprend un 
g6nerateur de tests relie d'une part aux moyens de reception de 

10 sequences-etalons et d'autre part aux moyens de reception de parametres 
statiques pour generer automatiquement un nombre elev6 de variantes de 
tests .qui sont transferees par des moyens de transfert pour etre stockees 
dans une base des variantes ; un exerciseur relie d'une part a des moyens 
de transfert pour recevoir les variantes de tests stock6es dans la base des 

15 variantes et d'autre part aux moyens de reception de parametres 
dynamiques pour ex£cuter les variantes de tests dans une plage de 
variation des parametres dynamiques et produire des resultats qui sont 
transferes par des moyens de transfert pour etre stockes dans une base 
des resultats ; et un analyseur relie a des moyens de transfert pour 

20 recevoir les resultats stockes dans la base des resultats, analyser ceux-ci 
et en deduire des regies d ! optimisation qui sont transferees par des 
moyens de transfert dans une base de regies d'optimisation. 

Avantageusement, I'analyseur comprend des moyens de filtrage 
a un seuil arbitraire de la performance optimale, de maniere S considerer 

25 une variante de la base des resultats comme optimale dans I'espace des 
parametres des lors qu T elle satisfait aux criteres de filtrage. 

Selon un mode de realisation preferentiel, I'analyseur comprend 
en outre des moyens de modification des parametres statiques et des 
moyens de modification des parametres dynamiques. 

30 Le dispositif d'optimisation et generation de code comprend un 

dispositif de generation de code optimise et un optimiseur, ce dernier 
comprenant un module de choix de strategie relte d'une pa rt a ux moysns.. 
de reception dss noyau:: identjfiSs dans les cod ss sources d'origine, 
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pluralrte de versions dont chacune est optimale pour une certaine 
combmateon de parametres, et un module de combinaison et 
d assemblage relie aux moyens de reception de regies d'optimisation, a 
des moyens de reception deformations issues du module de choix de 
strategy et a des moyens de reception de la pluralite des versions, pour 
del.vrer a travers des moyens de transfert des informations comprenant 
les versions optimisees correspondantes, leur zone d'utilisation et le cas 
plus e adaptee eSt * ^ dtonlner la version la 

10 Selon un mode de realisation optionnel preference!, le systeme 

comprend une base des noyaux optimises et le module de combinaison et 
d'assemblage est relie a la base des noyaux optimises par des moyens de 
mjnsM pour stocker dans cette base des noya'ux optS Ties 
mformat ons comprenant les versions optimisees, leur zone d'utilisation et 

::^r P r a : e P r * e * cuter pour — * 

comprenant un module de deteodon de boucles opbmlsables qui est 3*4 

decomposrtion en noyaux, un module d'analyse de cas, d'assemblage « 
d mjecbon de code qui est relie a travers des moyens de tranS t 
lopbm,seur pour transmettre rwenMfcaBon du noyau d&ecte a 2 
moyens de tansfert pour devoir les Informations SfaSThlS 
opqm.se correspondent, le module d'analyse de cas, dJ-n*LT^ 

srsir tont en — r * * - ~ 

Le module d'analyse de cas, d'assemblage et defection de 
«* Peut en o*e *e re „e a la base des noyaux opLisds pouTnS^ 
les mfbrmabons decrivant un noyau optimise sans Invoquer I'opamis^rl 
le noyau recherche y a (Stestocke. opumiseursi 

™ h* " ne raract&ls0c l ue avantageuse, le module d'analyse de 

cas d assemblage et d'injectlon de code comp^nd en outre des moyens 
pour rajouter aux sequences-talons des noyaux qui ont ete "Ten 
ev,dence dans ce module d'analyse de cas, d'assemblage et d'm^cuon 2 
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code sans avoir ^identification correspondante dans la base des noyaux 
optimises, ni dans les sequences-6talons. 

Selon un mode de realisation particuiier, le systeme comprend un 
compilateur et un 6diteur de liens pour recevoir un code source remanie 
5 issu du dispositif ^optimisation et generation du code et produire un code 
binaire optimise adapte a la plate-forme materielle. 

Le systeme peut comprendre des moyens pour transferer du code 
source des noyaux optimises de la base des noyaux optimises vers le 
compilateur. 

10 Selon une autre variante de realisation, le systeme peut 

comprendre un compilateur et un module d r installation pour installer sur la 
plate-forme materielle une bibliotheque dynamique contenant I'ensemble 
des fonctionnalites des noyaux optimises. 

L'invention peut s'appliquer a differents domaines duplication 

15 et notamment au calcul scientifique, au traitement de signal et au 
traitement graphique. 

Selon une caracteristique particuliere, les sequences-etalons 
comprennent un ensemble de codes de type boucle simples et generiques 
specifies dans un langage de type source et organises en niveaux de 

20 maniere hierarchique par ordre de complexite croissante du code du corps 
de boucle. 

Dans ce cas, les sequences-etalons comprennent des 
sequences-etalons de niveau 0 dans lesquelles une seule operation 
etementaire est testee et correspond a un corps de boucle constitue d'une 
25 seule expression arithmetique representee par un arbre de hauteur 0. 

En supplement, les sequences-etalons peuvent comprendre des 
sequences-etalons de niveau 1 pour lesquelles sont considerees et testees 
les combinaisons de deux operations de niveau 0, les operations des 
sequences-etalons de niveau 1 correspondant a des corps de boucles 
30 constitues. soit d f une seule expression arithmetique representee par un 
arbre de hauteur l f soit de deux expressions arithmetiques, chacune etant 
representee par un arbre de hauteur 0. 

Scion un rnodB de realisation possible, !es siquencas-etaion^ 
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Les parametres statiques comprennent notamment le nombre 
^iterations de la boucle pour chaque sequence-etalon, le pas d'acces aux 
tableaux et le type d'operande, le type destructions utilisees, les 
strategies de prechargement, les strategies d'ordonnancement' des 
instructions et des iterations 

Les parametres dynamiques comprennent notamment la 
localisation des operandes tableaux dans les differents niveaux de la 
hierarchie memoire, la position relative des adresses de depart des 
tableaux et ITiistorique des branchements. 

Avantageusement, la base des noyaux optimises comprend des 
sequences de code source de type boucle correspondant a des fragments 
de code reel et utile et organises en niveaux par ordre de complexity 
croissante. 

La plate-forme materielle predefinie peut comporter par 
exemple au moins un processeur du type denomme Itanium™ de la 
societe INTEL ou au moins un processeur du type Power ou Power PC™ 
de la soci<§te IBM. 

Selon un mode de realisation possible applicable plus 
particulierement aux systemes comportant un processeur de type 
ITANIUM™, les regies d'optimisation comprennent au moins certaines des 
regies suivantes : 

(a) minimiser le nombre d'Ecritures en cas de mauvaise performance 
desEcritures par rapport aux Lectures, 

(b) importance de ['utilisation des paires de chargement en virqule 
25 flottante, 

(c) ajuster le degre de deroulage en fonction de la complexite du corps 
de boucle, 

(d) utiliser les latences operationnelles des operations arithmetiques, 

(e) appliquer des techniques de masquage pour les vecteurs courts, 

30 (f) utiliser des suffixes de localite pour les acces memoire (Lecture 
Ecriture, Prechargement), 

(g) definir les distances de Prechargement, 
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(h) effectuer une vectorisation de degre 4 pour eviter une partie des 
conflits de bancs L2, 

(i) prendre en compte de multiples variantes pour eviter une autre 
partie des conflits de bancs L2 et les conflits dans la file d f attente des 

5 Lectures/Ecritures, 

0) prendre en compte les gains de performances lies aux differentes 
optimisations, 

(k) utiliser des chaTnes de branchement minimisant les mauvaises 
predictions (vecteurs courts), 

10 (I) fusionner les acces memoires (regroupement de pixels), 

(m) vectoriser les traitements sur pixels. 

Selon un autre mode de realisation possible applicable plus 
particulierement aux systemes comportant un processus de type Power ou 
15 Power PC™, les regies d'optimisation comprennent au moins certaines des 
regies suivantes : 

(a) reordonnancer les Lectures pour regrouper les defauts de caches, 

(b) utiliser le prechargement uniquement sur les Ecritures, 

(c) ajuster le degre de deroulage en fonction de la complexite du corps 
20 de boucle, 

(d) utiliser les latences op£rationnelles des operations arithmetiques, 

(e) utiliser des suffixes de localite pour les acces memoire (Lecture, 
Ecriture, Prechargement), 

(f) deflnir les distances de Prechargement, 

25 (g) prendre en compte de multiples variantes pour eviter les conflits dans 
les files d'attente Lecture/Ecriture, 

(h) prendre en compte les gains de performances lies aux differentes 
optimi£S3iions. 
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- la Figure 1 est un schema-bloc montrant ('ensemble des modules 
d'un systeme de generation automatlque de codes optimises selon 
('invention, 

- la Figure 2 est un schema-bloc montrant de facon plus detalllee la 
5 constitution d'un module d'analyse de performances pouvant etre mis en 

ceuvre dans le systeme de la Figure 1, 

- la Figure 3 est un schema-bloc montrant de facon plus detaillee la 
constitution d'un module d'optimisation et de generation de code pouvant 
etre mis en oeuvre dans le systeme de la Figure 1, 

10 - la Figure 4 est un schema bloc montrant un premier exemple de 

module de generation de code source remanie, associe a des moyens 
d'obtention de code binaire optimise pour la plate-forme cible concernee 
et ' 
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- la Figure 5 est un schema bloc montrant un deuxieme exemple de 
module de generation de code source remanie, associe a des moyens 
d'obtention de code binaire optimise pour la plate-forme cible concernee 

On se referera tout d'abord a la Figure 1 qui montre I'ensembfe du 
systeme de gen6ration automatique de code optimise pour fournir sur 
une sortie 73 d'un module 80 d'optimisation et de generation de code' des 
codes optimises operationnels sur une plate-forme materielle 90 prede'finie 
compoitant au moins un processeur 91. 

Le systeme de generation de code optimise est adapte a un 
domaine d'application determine et recoit, par une entree 71 du module 
80, des codes sources 17 soumis par des utilisateurs, le terme utilisateurs 
devant s'entendre au sens large et incluant notamment les utilisateurs 
finaux, les programmeurs d'applications ou les programmeuns systemes . 

Des sequences de code symboliques dites sequences-etalons 1 
representatives du comportement du processeur 91 en termes de 
performances pour le domaine d'application considere, sont appliquees sur 
une entree 52 du module 80 d'optimisation et de generation de code et 
sur une entree 51 d'un module d'analyse 10. 

L'analyse de I'effet des divers parametres de I'environnement et de 
('interaction entre sequences-etalons permet de situer les zones de bonnes 
et mauvaises performances et d'en apprehender les raisons. Les 
sequences-etalons ne represented pas forcement des sequences de code 
reel gener<§ par les langages de programmation classiques. Seul un sous- 
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ensemble des sequences-etalons testees correspond a des noyaux utilises 
pour roptimisation du code utilisateur. 

Une boucle optimisable est une construction de programme codant 
la representation algorithmique d'une operation plus ou moins complexe 
5 sur des variables-vecteurs. 

Un noyau ou boucle elementaire constitue une forme simple de 
boucle optimisable. Le module 80 du systeme selon ('invention permet de 
g£nerer automatiquement un nombre de noyaux optimises sensiblement 
superieur au. nombre de fonctions offertes par les bibliotheques 
10 specialisees mathematiques. En general, plusieurs versions d'un meme 
noyau peuvent etre generees, chaque version etant optimisee pour une 
certaine combinaison de parametres d'environnement. 

La phase d'optimisation dans un optimiseur 12 (Figure 3) consiste 
ainsi en la generation automatique d'un ensemble ou bibliothdque de 
15 noyaux optimises pour la plate-forme cible 90 representant des 
fonctionnalites representatives du domaine duplication. 

La phase d'optimisation est associee a une phase de generation de 
code dans un generateur de code 18 (Figure 3) qui examine le code 
source du programme utilisateur pour y detecter les boucles optimisables 
20 afin de forcer Tutilisation de noyaux optimises en lieu et place du code 
qu'aurait genere le compilateur standard. 

Des moyens 74 sont prevus pour reinjecter dans les sequences- 
etalons 1 les informations issues du module 80. 

Les phases d'optimisation et de generation de code sont prec&jees 
25 par une phase d'analyse dans un module d'analyse 10 qui sert a 
determiner, pour la plate-forme materielle cible 90 et le domaine 
duplication considere, les regies d'optimisation a respecter pour obtenir 
des performances optimales. Une sortie 57 du module d'analyse 10 
permet le transfert des regies d'optimisation vers une base 9 de regies 
30 d'optimisation elle-memer reliee, par des moyens de transfert 18, a 
I'optimissur 12 du module 80. 

On decrira maintenant de racon plus particuliere le module 
d'analyse 10 en rsfSrBTFcri la Figure 2. 
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('optimisation, et egalement en fonction des sequences-etalons, sont 
appliques par des moyens 53, 54 au module d'analyse 10. 

Les parametres statiques 2 peuvent comprendre notamment le 
nombre derations de la boucle pour chaque sequence-etalon, le pas 
d'acces aux tableaux et le type d'operande, le type destructions utilisees 
les strategies de prechargement, les strategies d'ordonnancement des 
instructions et des iterations. 

Les parametres dynamiques. 7 peuvent comprendre notamment la 
localisation des operandes tableaux dans les differents niveaux de la 
hierarchie memoire, la position relative des adresses de depart des 
tableaux et I'historique des branchements. 

Dans le module 10 d'analyse de performances, un generateur de 
test 3 exploite les donnees relatives aux parametres statiques 2 et 
dynamiques 7, qui lui sont fournies par les entrees 51, 53 pour generer un 
15 nombre potentiellement tres eleve" de variantes qui sont transferees par 
des moyens de transfert 61 vers une base de donnees des variantes 4. 

Un autre outil automatique 5 denomme exerciseur regoit, par des 
moyens de transfert 62, les donnees des variantes et la base des variantes 
4, met en ceuvre les tests ainsi fabriques, les execute en faisant varier 
dans leur plage de variation les parametres dynamiques 7 fournis par ies 
moyens de transfert 55 et transfere, par des moyens de transfert 63 les 
mesures pertinentes vers une autre base de donnees 6 denommee base 
des resultats. 

Les mesures stockees dans la base des resultats 6 sont elles- 
memes transferees, par des moyens de transfert 64, vers un analyseur 8 
qu., a partir de ('identification des zones de bonne et mauvaise 
performance en fonction du parametrage, permet Ja formulation des 
regies d'optimisation 9 qui sont transferees par les moyens de transfert 57 
dans la base 9 de regies d'optimisation. 

L'analyseur 8 comprend egalement des moyens 54 de modification 
des parametres statiques 2 et des moyens 56 de modification des 
parametres dynamiques, par exemple s'il a ete constate une faible 
sensibility aux variations d'un parametre donne. 

L'analyseur 8 peut comprendre des moyens de filtrage a un seuil 
arbitraire de la performance optimale. Dans ce cas, une variante de la 
base des resultats qui ne correspond pas a des performances optimales 
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peut neanmoins etre retenue comme optimale dans Pespace des 
parametres, des lors qu'elle satisfait aux criteres de filtrage. 

On decrira maintenant le module 80 d'optimisation et de generation 
de code en reference a la Figure 3. 

5 Le dispositif d'optimisation 12 comprend un module 13 de choix de 

strategie relie au module 18 de generation de code par des moyens 92 de 
reception des noyaux identifies dans les codes sources d'origine. Le 
module 13 de choix de strategie est en outre relie a des moyens 52 de 
reception de sequences-6talons 1 et a des moyens 58 de reception de 

10 regies d'optimisation 9. Le module 13 de choix de strategie genere a sa 
sortie 67, pour chaque noyau correspondent a une sequence-6talon 
testee, un ensemble 15 de n versions dont chacune est optimale pour une 
certaine combinaison de parametres. 

Un module 14 de combinaison et d'assemblage de versions est relie 

15 aux moyens 59 de reception de regies d'optimisation 9, a des moyens 66 
. de reception ^informations issues du module de choix de strategie 13 et a 
des moyens 68 de reception de la pluralite 15 de versions 1 a n. Le 
module 14 delivre a travers des moyens de transfert 93 des informations 
comprenant les versions optimisees correspondantes, leur zone 

20 d'utilisation et le cas echeant le test a executer pour determiner 
dynamiquement la version la plus adaptee. 

Le module 18 de generation de code optimise comprend un module 
20 de detection de boucles optimisables qui est relie a des moyens 71 de 
reception des codes sources 17 d'utilisateurs. La sortie 75 du module 20 

25 est reliee a un module 22 de decomposition en noyaux dont la sortie 77 
est elle-meme reliee a un module 23 d'analyse de cas, d'assemblage et 
d'injection de code qui est relie, a travers des moyens de transfert 92, a 
Poptimiseur 12 pour transmettre ('identification du noyau detecte. Le 
module 23 report par ailleurs, par des moyens de transfert 93, les 

30 informations decrivant le noyau optimise correspondant Le module 23 est 
aussi relie a des moyens 73 de fourniture des codes optimises 19. 

Selon une variante de realisation avantageuse, le module 80 
d'optimisation et de gineratjori de code comprend une tose des noyau:: 
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les versions optimisees, leur zone d'utilisation et le cas echeant le test a 
exporter pour determiner dynamiquement la version la plus adaptee 
Selon cette variants le module 23 d'analyse de cas, d'assemblage et 
d'injection de code est en outre relie a la base 16 des noyaux optimises 
5 par les moyens de transfert 72 pour recevoir les informations decrivant un 
noyau optimise^ sans invoquer I'optimiseur 12, si le noyau recherche a 
deja ete stocks dans cette base 16. 

Comme on peut le voir sur la Figure 3, le module 23 d'analyse de 
cas, d'assemblage et d'injection de code comprend en outre des moyens 
10 74 pour rajouter aux sequences-etalons 1 des noyaux qui ont ete mis en 
evidence dans ce module 23 sans avoir I'identification correspondante 
dans la base 16 des noyaux optimises, ni dans les sequences-etalons. 

La Figure 4 montre un exemple particulier de realisation pour lequel 
on n'a pas represente I'optimiseur 12 qui reste identique a la variante de 
15 la Figure 3 selon laquelle il existe une base 16 des noyaux optimises 

Dans cet exemple de realisation, le module 18 de generation de 
code produit en sortie 73 du module 23 d'analyse de cas, d'assemblage et 
d'injection de code,, un code source remanie 19 qui est ensuite traite par 
des outils classiques de preparation de programme 81, 82 pour I'obtention 
20 de code binaire 83 optimise pour la plate-forme cible 90. 

La Figure 4 represente un exemple de realisation qui peut etre tres 
faclement mis en oeuvre. Le code source utilisateur d'origine 17 a ete 
remanie au sein du module 80 d'optimisation et de generation de code 
deja decrit plus haut, de telle maniere que les boucles optimisables soient 
remplacees par des appels a des sous-programmes, le code correspondant 
a ces sous-programmes etant injecte dans le code source remanie 19 
depuis la base des noyaux optimises 16. Le code source 19 ainsi remanie 
conbent alors tout le necessaire pour generer un code binaire optimise 83 
adapte a la plate-forme materielle 90, par un passage dans une chaine 
30 classique comprenant un compilateur 81 et un editeur de liens 82. 

Selon une variante possible, du code source des noyaux optimises 
de la base des noyaux optimises 16 peut etre utilise directement dans 
letape de compilation en tant que bibliotheque source d'appoint. Ceci est 
symbolise sur la Figure 4 par la fleche en pointilles 85 qui relie la base des 
noyaux optimises 16 au compilateur 81. Cette variante permet ainsi 
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d'eviter Pinjection directe de ce code source des noyaux optimises dans le 
code source remante et allege Petape de generation au sein du module 18. 

La Figure 5 represente une autre variante de realisation de 
Pexemple de realisation de la Figure 4. 
5 La variante de la Figure 5 exploite la possibility qu'offrent certains 

systemes d'exploitation d'installer des bibliotheques sous forme de codes 
binaires executables et accessibles par des programmes par edition de 
liens dynamiques au moment de leur execution. 

Dans le cas de la variante de la Figure 5, il n'est pas non plus 

10 necessaire d'injecter de code depuis la base des noyaux optimises 16 vers 
le code source remanie 19. En revanche, une bibliotheque dynamique 
contenant Pensemble des fonctionnalites des noyaux optimises doit etre 
installee sur la plate-forme cible 90 par Pintermediaire d f un compilateur 
181 et d f un module d'installation 182. On peut utiliser un seul compilateur 

15 commun pour les compilateurs 81 et 181 de la Figure 5. Dans cette 
variante de la Figure 5, Poperation d'installation n r est necessaire qu'une 
seule fois pour chaque plate-forme cible, de sorte que cette variante est la 
plus econome en termes de traitement global du processus d'optimisation. 
La mise en oeuvre d'un systeme de generation de code optimist 

20 selon Pinvention s'applique particulierement bien aux trois domaines que 
sont le calcul scientifique, le traitement du signal et le traitement 
graphique. 

En effet, les codes utilises dans ces trois domaines presentent 
plusieurs caracteristiques CAR1 a CAR4 qui sont importantes pour cette 
25 mise en ceuvre. 

o CAR 1 : Les structures de type boucle (ou « nids de boucle ») 
constituent les portions de code les plus consommatrices en termes 
de temps d'execution 
o CAR 2 : Les structures de donnees utilisees sont en majeure partie 
30 de type tableau multidimenslonnel et sont accedees suivant des 

motifs tres r^guliers (lignes, colonnes, blocs, etc.) 
CAR 3 : Les. uducIcs (ou nid5 da boucles) zont en general 
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o CAR 4 : Le corps de fa boucle est en general consHtue d'une 
sequence d'expresstons arithmedques et correspond a un calcul 
uraforme (ou quasl-uniforme) sur un grand volume de donnees. 

trairerr^T" 6 " 18 ?' " °" ** dU Calcul * 

foment de s,gnal et du traitement graphs des ^ 

commons ,1s presented aussi certaines differences fortes. Ainsi „ 

domame du traitement de signal, les donnees de type comolexe 

constituent un type de donnees extrememem Important qTreq" 

opom.sadons speclnques tandls que .Importance de ce t^ de donees 

partil e 1 T marqU ' '' UH,,SSt,0n *" *» 

parecuner les p K els, et d'une anthmftique speciale. De plus en 

9 aph,que ,a station des donneee e, des algorithmes par 
unecranbidimenslonnelestfbndamentale. ra PI»rta 
Les quatre caratteristlques d-dessus (CAM i CAR4) ont des 
consequences bres fortes pour ,'opdmisabon de code et permelt e 
developpement de techniques complement specMques- 

° T teSOpHmlSat ' onsTOnte "^^concentrer S urles 

structures de type «boude» .qul pnisentent deux avantac- 

SILT" - ( * p *™> « ~ ^ 

o CAR 2 => les acces aux tableaux qui representent one part 
(voire majeure en reison de ,'ud„sadon creissanre Z 
caches, des te mps d'exfeudon vont pouvolr focilement etre 
analyses et optimises en raison de leur regularity 

° ^I* V.T- I1nd ^ endancedes ausein d'une boucle 

et de n,ds de boudes, va permettre I'utlllsation (('optimisation) de 
psreours de ,'espace dTreredon en foncdon des aU aux S£ 

ce su tent ies carectedsdques prepres de .'architecture 
pent remarquer qu'acceder a N elements donnes d'un tableau peu" 
etre reatee de N I manieres (ordres) different*. 
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o CAR 4 n== ^ > la structure simple du corps de boucles en termes 
d'expressions arithmetiques va nous permettre d'utiliser une 
approche systematique et hierarchique s'appuyant sur la 
representation sous forme d'arbres d'une expression arithmetique. 

5 

La phase d'analyse reste une phase essentiellement experimental 
a Tissue de laquelle il faut : 

• avoir determine les points forts et les points faibies de 
('architecture, 

10 • savoir correler performance et structure de code, 

• avoir identifie les bonnes strategies d'optimisation, celles ci 
pouvant etre fonction de differents param£tres lies au code. 

Comme on l f a deja indiqu£, le point de depart est un ensemble de 
15 codes « de type source » simples mais generiques appeles « sequences- 
etalons ». Ces codes ont une structure de type boucle, ie terme « type 
source » indiquant que les operations sont specifiees a haut niveau et non 
au niveau assembleur. 

Ces codes sont organises en niveaux de maniere hierarchique par 
20 ordre de complexity croissante du code du corps de boucle de la maniere 
suivante : 

o SEQUENCE-ETALON NIVEAU 0 : a ce niveau, une seule operation 
elementaire est testee, c'est-a-dire que le corps de boucle comporte 
une seule operation : lecture d'un element de tableau, ecriture d'un 
25 element de tableau, addition flottante, etc Ces operations 

correspondent a des corps de boucle constitue d'une seule 
expression arithmetique representee-par un arbre de. hauteur 0. 
o SEQUENCE-ETALON NIVEAU 1 : a ce niveau, sont considerees et 
testees les combinaisons de deux operations de niveau 0 : lecture 
1:0 zi Bcriture dun tobl=£u. lecture d-s^deu:: feblsau:: different. 
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arithmetique representee par un arbre de hauteur 1, soit deux 
expressions arithmetiques, chacune etant representee par un arbre 
de hauteur 0. 

• SEQUENCE-ETALON NIVEAU 2 : a ce niveau les combinaisons de 
5 deux operations de niveau 1 ou de trois operations de niveau 0 

sont considerees et testees : lecture de trois tableaux differents, 
lecture et addition de deux tableaux composante a composante et 
ecriture du resultat dans un troisieme tableau etc. 

• SEQUENCE-ETALON NIVEAU K : le niveau K peut etre aisement 
10 ddfini par recurrence a partir des niveaux precedents. 

Toutes les sequences-etalons de niveau 0 correspondent a des 
codes qui sont « artificiels », i.e. ne traduisent pas des boucles « belles ». 

Cette organisation en niveaux de complexity croissante est aussi 
utilisee dans la phase d'optimisation. 
15 L'ensemble des sequences-etalons ainsi defini est infini. 

Ces sequences-etalons utilisent deux classes de parametres differents : 

• Parametres statiques: ces parametres sont definis de maniere 
statique (c*est-a-dire avant execution et independamment de 

10 I'execution). Ces parametres statiques sont eux mimes subdivises 

en deux grandes sous classes: parametres statiques de haut 
niveau (nombre d'iterations de la boucle, pas d'acces aux tableaux, 
type d'operande,...), parametres statiques de bas niveau 
(utilisation dlnstructions specifiques, ordonnancement des 

5 instructions etc.) 

• Parametres dynamiques : ces parametres sont definis lors de 
I'execution de la boucle. lis comprennent par exemple : localisation 
des operandes tableaux dans la hierarchie memoire, position 
relative des adresses de depart des tableaux,... 



0 



Ces deux classes de parametres sont exploitees de maniere tres 
differente: les. parametres statiques seront utilises pour generer les 
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differents codes tests en combinaison avec les variantes/optimisations 
decrites ci-dessous, tandis que les parametres dynamiques sont 
exclusivement utilises lors de I'execution sur le banc de test. 

Les parametres statiques de haut niveau sont relativement limites 
5 et correspondent essentieilement aux parametres classiques d'une boucle 
et de tableaux exprimes dans un langage haut niveau (Fortran ou C par 
exemple) sans aucune specificite provenant du processeur cible. 

Les parametres statiques de bas niveau vont permettre de prendre 
en compte toutes les specificites liees au processeur (architecture) et a 

10 I'ordonnancement des instructions (generateur de code objet). En effet, 
les sequences-etalons sont de fait des abstractions a haut niveau (definies 
dans un langage source, independantes de ['architecture du processeur 
vise) et nlntegrent en particulier aucune optimisation. Pour les tester sur 
un processeur donne, il faut generer et optimiser les codes assembleurs 

15 correspondants. Lors de cette generation, plusieurs variantes (sequence 
destructions assembleurs) vont etre gener£es automatiquement Toutes 
les variantes associees a une meme sequence-etalon sont des codes 
semantiquement equivalents a la sequence-etalon de depart. Ce sont ces 
variantes qui vont etre executees et mesur^es. Ces variantes 

20 correspondent en fait a differentes techniques d'optimisation de code 
(c'est-a-dire a des parametres statiques de bas niveau). Ces optimisations 
peuvent etre definies de maniere abstraite sans reference a la structure 
particuliere d'une sequence-etalon et constituent Tessentiel des 
parametres statiques de bas niveau. 

25 

Les parametres statiques de bas niveau component : 
© ('utilisation- des instructions assembleurs: une meme operation au 
niveau source peut etna mise en oeuvre par differentes sequences 
dlnstructions. En particulier, il faut traiter ici les difP4 rentes 
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• la structure du corps de boucle : deroulage (degre variable) du 
corps de boucle, 

• I'ordonnancement du corps de boucle : ordonnancement des 
instructions du corps de boucle (distances de prechargement, 

5 vectorisation), regroupement des defaut de cache, traitement des 

conflits dans le files d'attente), 

• I'ordonnancement des iterations : pipeline loglciel (profondeur 
variable) 



10 Dans nombre de compilateurs, les parametres statiques de bas 

niveau droits ci-dessus correspondent a des options de /compilation 
permettant de mettre en oeuvre de maniere explicite I'optimisation visee. 

Le r6le du generateur de test 3 est de generer les differentes 
variantes decrites ci-dessus correspondant d'une part aux parametres 
15 statiques de haut niveau (par exemple, pas d'acces aux tableaux) et 
d'autre part aux parametres statiques de bas niveau. 

II faut noter que pour des sequences-etalons de niveau 1, le 
nombre total de variantes a generer/analyser est extremement Sieve et se £ 
chiffre a plusieurs millions. Malgre cela, le processus de generation et i r '' 
20 d'analyse peut §tre tres simplement automatism. 

Au niveau de Texerciseur 5 et de Tanalyseur 8, il s'agit de tester les 
, performances des differentes variantes et de selectionner les meilleures 
variantes/optimisations possibles. 

Cette phase implique la generation d f un grand nombre de n&ultats 
25 stockes dans la base de resultats 6. Les experimentations sont effectuees 
de maniere hierarchique et entrelacee avec les phases d'analyse : ainsi les 
premieres experimentations sont effectuees sur les variantes des 
sequences-etalons de niveau 0. A tissue de cette premiere campagne 
d'exp^rimentation, un premier tri sur les differentes variantes peut etre 
30 effectue en fonction des resultats obtenus. Certaines variantes peuvent 
ainsi etre tout de suite eliminees et ne seront plus considerees pour les 
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niveaux suivants. Ceci permet de limiter I'explosion combinatoire du 
nombre d'experiences a r6aliser. 

La phase d'analyse des resultats est a premiere vue assez simple a 
effectuer car une seule metrique (performance) est utilis6e. En fait une 
5 grande partie de la complexity du processus provient du fait qu'en 
general, le choix des meilleures variantes va tres fortement dependre des 
parametres. 

Un premier tri peut etre realise de maniere tres simple en 
calculant d'apres les specifications de ('architecture, les performances 

10 optimales pour chacune des sequences-etalons. Par contre, des difficultes 
peuvent apparaftre rapidement, liees aux interactions complexes entre 
architecture et codes (y compris pour des codes aussi simples que les 
sequences-etalons de niveau 0 et 1): ceci se traduit par des figures 
compliquees decrivant les variations de la performance en fonction des 

15 parametres. Ces comportements complexes peuvent §tre d'abord analyses 
en utilisant des algorithmes de traitement dlmage puis synthetises en 
qualifiant une variante donnee pour une certaine plage de parametre. 
Ainsi la phase d'analyse ne genere pas simplement une liste indiquant 
pour chaque sequence-etalon la meilleure (et unique) variante/technique 

20 d'optimisation : de fait pour chaque sequence-etalon, une liste de plages 
de parametres est determinee et, pour chacune de ces plages, la meilleure 
variante/technique d'optimisation est indiquee : c'est une telle information 
qui sera appelee « regie d'optimisation ». 

L'ensemble des sequences-etalons testees est un sous-ensemble 

25 tres restreint de l'ensemble des sequences-etalons. Cet ensemble qui est 
utilise par la suite pour les optimisations est appele « ensemble des 
sequences-etalons de reference ». 

En pratique, il est tres important de fixer un objectif 
<: raisonnabie * d'optimisation : ainsi chercher a tout pri:c i'optimum peut 

?Q G=n~r=r un nombre tres el~ve de vr»ri3nt23 alors.. qu'en relschant b 
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pour une grande plage de parametres. On precede pour cela a un filtrage 
par exemple a un seuil de 90% de la performance optimale. 

En pratique, II sufflt de tester et d'analyser seulement les niveaux 
0, 1 et 2 des sequences-etalons pour degager et vallder les principales 
5 techniques d'optimisatlon. L'ensemble de reference des sequences-etalons 
ne contiendra pas en general de sequence de niveau superieur a 3. 

En effet, le volume d'experimentations devient rapidement tres 
eleve en particulier au-dela du niveau 2. 

L'ensemble des experimentations se prete de maniere ideale a la 
10 parallelisation : les tests peuvent etre executees en parallele sur 100 ou 
1000 machines. Cette propriete de parallelisation est extremement utile et 
permet d'effectuer des explorations systematiques et ceci dans des temps 
acceptables. 

Cette phase est entierement automatisable et les procedures de 
15 verification de quality et de coherence des resultats peuvent etre aussi 
automatisees. Intervention humaine n'est requise que pour le releve 
d'erreurs/anomalies decoulant de I'ahalyse des resultats produits 
automatiquement par les procedures de verification de qualite et de 
coherence. 



20 



A tissue de la phase d'analyse, I'objectif est de disposer d'un tres 
grand nombre de codes simples dits « noyaux » specifiquement optimises 
pour ('architecture cible, ce processus d'optimisation s'appuyant de 
maniere essentielle sur les techniques d'optimisation degagees a Tissue de 
la phase d'analyse. 

25 De maniere stride, les « noyaux » sont des sequences de code 

source de type boucle et constituent un sous-ensemble du cas general des 
sequences-etalons. A la difference de ces dernieres, ils correspondent a 
des fragments de code reel et utile. Comme les sequences-etalons, ils sont 
organises en niveaux par ordre de complexite croissante. 

30 La generation/optimisation de ces noyaux se deroule suivant les 

quatre phases ci dessous : 
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o Correlation avec une ou plusieurs sequences-etalons de reference : 
pour les noyaux les plus simples, il y a une correspondence directe 
entre noyaux et sequences-etalons, pour les noyaux plus 
complexes, le noyau sera decompose en plusieurs sequences- 
5 etalons de reference. Cette correlation/decomposition est effectuee 

au niveau source en fonction des caracteristiques du corps de 
boucle du noyau : nombre de tableaux, pas d'acces aux tableaux, 
etc... . 

. o Generation de code/Ordonnancement dlnstructions/optimisation 
10 destructions : il s'agit d'utiliser les techniques d'optimisation 

detectees lors de la phase d'analyse (en fonction des sequences- 
etalons correspondantes) et de les appliquer directement a la 
generation / optimisation de code pour les noyaux. Pour un meme 
noyau, plusieurs versions possibles pourront etre generees et ce en 
15 fonction des parametres. 

o Allocations de registre : bon nombre des techniques d'optimisation 
utilisees accroissent de maniere sensible la pression sur les 
registres disponibles. Dans ce cas, il convient d'amenager 
('allocation de ('ensemble des registres disponibles. 
20 o Experimentation/Validation : le noyau genere et optimise est teste 
en utilisant le banc de test de la phase d'analyse. A tissue de cette 
phase, un modele simple des performances du noyau est construit. 
Par rapport aux optimisations classiques utilisees dans un 
compilateur, les optimisations utilisees ici sont tres differentes : tout 
25 d'abord elles sont derivees directement d'un processus detaille 
devaluation de performances (effectue lors de la phase d'analyse) ensuite 
elles sont beaucoup plus complexes et performantes (en particulier pour 
1'ailocation de registres) car elles sont executees hors connexion sans 
contrainte: de temps. 
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mesurees et non theoriques) et d'autre part les differentes versions 
devant etre selectionnees en fonction des parametres. 

A llssue de cette phase, il a ete construit une base de donnees 16 
des noyaux optimises, contenant non seulement les codes generes mais 
aussi les informations relatives aux performances et ceci en fonction des 
differents parametres. Chacun de ces noyaux est d'ailleurs teste suivant la 
procedure utilisee pour les sequences-etalons. 

En pratique, la base 16 des noyaux optimises comprend de 
maniere systematique et exhaustive tous les noyaux de niveaux 1, 2, 3, 4 
et 5. Le cout en termes de volume de calcul de la construction de cette 
base de donnees est important mais comme pour la phase analyse de 
performances, elle se parallelise tres efficacement. 

L'optimisation du code utilisateur se deroule en trois phases : 
o Detection des boucles optimisables (module 20) : il s'agit de 
reconnaitre au sein du code source les boucles pouvant etre 
decomposees en noyaux. Cette phase utilise des techniques tres 
proches de cede des paralleliseurs/vectoriseurs automatiques. Au 
besoin, le code source est restructure pour faire apparaitre la 
boucle sous la forme la plus favorable a l'optimisation 
o Analyse de la boucle optimisable, decomposition en noyaux 
(module 22) : en s'appuyant sur des techniques d'appariement de 
configuration et de decomposition proches de celles utilisees pour 
l'optimisation des noyaux, la boucle est decomposee en une 
sequence de noyaux 
o Assemblage et injection de code (module 23) : les differents 
noyaux utilises pour la decomposition sont assembles et reinjectes 
dans le code source. 

La procedure de decomposition est en general parametree en 
fonction de caracteristiques de la boucle source d'origine. 
Les optimisations proposees peuvent etre integrees 
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o soit par un pr£-processeur dans un chatne de compilation existante 
et ceci de maniere transparente c'est-a-dire sans qull soit 
necessaire d'avoir acces au code du compilateur, 

o soit directement dans un compilateur, ceci necessitant bien sur des 
5 modifications dans le code du compilateur. 

Comme on Pa deja indique plus haut en reference a la Figure 3, a 
Hssue de la phase d'analyse un certain nombre de regies d'optimisation 
. sont disponibles : ces regies sont fonction de la sequence-etalon et de la 

10 plage de parametre. Au lieu de passer par I'etape intermediate des 
noyaux, une variante possible est de correler directement la boucle 
optimisable avec les sequences-etalons et d'appliquer directement les 
regies d'optimisation sur la boucle optimisable sans passer par le stockage 
de noyaux dans une base 16 des noyaux optimises. 

15 Cette variante est plus simple que le passage par les noyaux et 

elle permet une utilisation plus souple des regies d'optimisation. En 
revanche, du fait qu ! elle est realisee essentiellement en ligne, le nombre 
de variantes explorees sera necessairement plus restreint et done les 
performances obtenues seront a priori un peu moins bonnes. 

20 A Tissue de la phase d'optimisation, le systeme a genere des 

formes optimisees pour un certain nombre de boucles « optimisables » qui 
a priori n'etaient pas directement disponibles dans la base des noyaux car 
elles avaient necessite une decomposition. Ces formes optimisees peuvent 
etre stockees dans la base 16 des noyaux optimises et reutilisees par la 

25 suite. Ainsi, la base de donnees 16 des noyaux est enrichie 
automatiquement par cette forme d'apprentissage. 
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1. Systeme de generation automatique de codes optimises ( 19) 
operationnels sur une plate-forme materielle predefine (90) component 
■ au moins un processeur (91), pour un domaine duplication predetermine 
a parbr de codes sources (17) soumis par des ublisateurs, caracterise en 
ce qu'il comprend des moyens (51, 52) de reception de sequences de 
codes symboliques dites sequences-etalons (1) representatives du 
comportement dudit processeur (91) en termes de performances, pour le 
domaine duplication predetermine ; des moyens (53) de reception de 
parametres statiques (2) definis a partir de la plate-forme materielle 
predefine (90), de son processeur (91) et des sequences-etalons (1) • des 

Zr S ^ 55 l de / 6CePtl0n dS Param ^ tres ty™™^ (7) egalement 
definis a partir de la plate-forme materielle predefine (90), de son 
processeur (91) et des sequences-etalons (1) ; un dispositif d'analyse (10) 
pour etablir des regies d'optimisation (9) a partir de tests et de mesures 
de performances etablis a partir des sequences-etalons (l) des 
parametres statiques (2) et des parametres dynamiques (7) ; un dis'positif 
(80) d optimisation et generation de code recevant d'une part les 
sequences-etalons (1) et d'autre part les regies d'optimisation (9) pour 
examiner les codes sources (17) d'utilisateurs, detecter des boucles 
opt.m.sables, decomposer en noyaux, assembler et injecter des codes 
pour delivrer des codes optimises (19) ; et des moyens (74) pour 
remjecter dans les sequences-etalons (1) des informations issues du 
noy^ ^ 9<§n(§rati ° n 6t °P timisation de codes et relatives a des 

2. Systeme selon la revendication 1, caracterise en ce que le 
d.spos.tif d'analyse (10) comprend un generates de tests (3) relie d'une 
part aux moyens (51) de reception de sequences-etalons et d'autre part 
aux moyens (53) de reception de parametres statiques pour generer 
automatiquement un nombre eieve de variantes de tests qui sont 
transferees par des moyens de transfert (61) pour etre stockees dans une 
base des variantes (4) ; un exerciseur (5) relie d'une part a des moyens 
de transfert (62) pour recevoir les variantes de tests stockees dans la base 
des variantes (4) et d'autre part aux moyens (55) de reception de 
parametres dynamiques pour executer les variantes de tests dans une 
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plage de variation des parametres dynamiques (7) et produire des 
resultats qui sont transf£res par des moyens de transfert (63) pour etre 
stockes dans une base des r6sultats (6) ; et un anaiyseur (8) relie a des 
moyens de transfert (64) pour recevoir les resultats stockes dans la base 
5 des resultats (6), analyser ceux-ci et en deduire des regies d'optimisation 
qui sont transferees par des moyens de transfert (57) dans une base de 
regies d'optimisation (9). 

3. Systeme selon la revendication 2, caracterise en ce que 
Tanalyseur (8) comprend des moyens de filtrage a un seuil arbitraire de la 

10 performance optimale, de maniere a considerer une variante de la base 
des resultats comme optimale dans I'espace des parametres des lors 
qu'elle satisfait aux criteres de filtrage. 

4. Systeme selon la revendication 2 ou la revendication 3, 
caracterise en ce que Tanalyseur (8) comprend en outre des moyens (54) 

15 de modification des parametres statiques (2) et des moyens (56) de 
modification des parametres dynamiques (7). 

5. Systeme selon Tune quelconque des revendications 1 a 4, 
caracterise en ce que le dlspositif (80) ^optimisation et generation de 
code comprend un dlspositif (18) de generation de code optimise et un 

20 optimiseur (12), ce dernier comprenant un module de choix de strategie 
(13) relie d'une part aux moyens (92) de reception des noyaux identifies 
dans les codes sources d'origine, d'autre part aux moyens (52) de 
reception de sequences-etalons (1) et d'autre part a des moyens (58) de 
reception de regies d'optimisation (9) pour generer, pour chaque noyau 

25 correspondant a une sequence-etalon testee une pluralite de versions (15) 
dont chacune est optimale pour une certaine combinaison de parametres, 
et un module de combinaison et d'assemblage (14) relie aux moyens (59) 
de reception de regies d'optimisation (9), a des moyens (66) de reception 
d'informations issues du module de choix de strategie (13) et a des 

30 moyens (68) de reception de la pluralite. des versions (15), pour delivrer a 
travers des moyens de transfert (93) des informations comprenant les 
versions optimisees- correspondantes, leur zone d'utilisation et le cas 
kheant !=: test a = :ecuter pour determiner dynamiquament la version Is 
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combinaison et d'assemblage (14) est relie a la base des noyaux optimises 
(16) par des moyens de transfert (79) pour stacker dans cette base des 
noyaux optimises les informations comprenant les versions optimisees, 
leur zone d'utilisation et ie cas echeant le test a executor pour determiner 
5 dynamiquement la version la plus adaptoe. 

7. Systeme selon Tune quelconque des revendications 1 a 6, 
caracterise en ce que le dispositif (80) d'optimisation et generation de 
code comprend un optimiseur (12) et un dispositif (18) de generation de 
code optimise^ ce dernier comprenant un module (20) de detection de 

10 boucles optimisables qui est relie a des moyens (71) de reception des 
codes sources (17) d'utilisateurs, un module (22) de decomposition en 
noyaux , un module (23) d'analyse de cas, d'assemblage et d'injection de 
code qui est reli<§ a travers des moyens de transfert (92) a I'optimiseur 
(12) pour transmettre Identification du noyau detecte et des moyens de 

15 transfert (93) pour recevoir les informations decrivant le noyau optimise 
correspondent, le module (23) d'analyse de cas, d'assemblage et 
d'injection de code etant en outre relie a des moyens (73) de fourniture 
des codes optimises. 

8. Systeme selon les revendications 6 et 7, caracterise en ce 
20 que le module (23) d'analyse de cas, d'assemblage et d'injection de code 

est en outre relie a la base (16) des noyaux optimises pour recevoir les 
informations decrivant un noyau optimist sans invoquer I'optimiseur (12) 
si le noyau recherche y a eta stocke. 

9. Systeme selon la revendication 8, caracterise en ce que le 
25 module (23) d'analyse de cas, d'assemblage et d'injection de code 

comprend en outre des moyens (74) pour rajouter aux sequences-etalons 
(1) des noyaux qui ont ete mis en evidence dans ce module (23) d'analyse 
de cas, d'assemblage et d'injection de code sans avoir ^identification 
correspondante dans la base (16) des noyaux optimises, ni dans les 
JO sequences- etalons. 

10. Systeme selon I'une quelconque des revendications 6, 8 
et 9, caracterise en ce qu'il comprend un compilateur (81) et un editeur de 
liens (82) pour recevoir un code source remanie (19) issu du dispositif 
(80) d'optimisation et generation du code et produire un code binaire 

15 optimise (83) adapta a la plate-forme matarielle (90). 
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11. Systeme selon la revendication 10, caracterise en ce qu'il 
comprend des moyens (85) pour transferer du code source des noyaux 
optimises de la base des noyaux optimises (16) vers le compilateur (81). 

12. Systeme selon la revendication 10, caractense en ce qu'il 
5 comprend un compilateur (181) et un module d'installation (182) pour 

installer sur la plate-forme materielle (90) une bibliotheque dynamique 
contenant I'ensemble des fondn'onnalites des noyaux optimises. 

13. Systeme selon Tune quelconque des revendications 1 a 12, 
caracterise en ce que le domaine d'application predetermine est le calcul 

10 scientifique. 

14. Systeme selon I'une quelconque des revendications 1 a 12, 
caracterise en ce que le domaine d'application predetermine est le 
traitement du signal. 

15. Systeme selon I'une quelconque des revendications 1 a 12, 
15 caracterise en ce que le domaine d'application predetermine est le 

traitement graphique 

16. Systeme selon I'une quelconque des revendications 1 a 15, 
caracterise en ce que les sequences-etalons (1) comprennent un ensemble 
de codes de type boucle simples et generiques specifies dans un langage 

20 de type source et organises en niveaux de maniere hierarchique par ordre 
de complexity croissante du code du corps de boucle. 

17. Systeme selon la revendication 16, caracterise en ce que 
les sequences-etalons (1) comprennent des sequences-etalons de niveau 
0 dans lesquelles une seule operation elementaire est testee et 

25 correspond a un corps de boucle constitue d'une seule expression 
arithmetique representee par un arbre de hauteur 0. 

18. Systeme selon la revendication 17, caracterise en ce que 
les sequences-etalons comprennent des sequences-etalons de niveau 1 
pour lesquelles sont considerees et testees les combinaisons de deux 

30 operations de niveau 0, les operations des sequences-etalons de.niveau 1 
correspondent a des corps de boucles constitues soit d'une seule 
expression arithmetiqua representee par un arbre de hauteur 1„ soit ds 
•Jeu:. abrasions aritiimitiquas, chacurje scant r=prssent4= oar un srtre 
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2 pour lesquelles sont considerees et testees les combinaisons de deux 
operations de niveau 1 ou de trois operations de niveau 0. 

20. Systeme seion Tune quelconque des revendications 16 a 
19, caracterise en ce que les parametres statiques (2) comprennent 

5 notamment le nombre derations de la boucle pour chaque sequence- 
etalon, le pas d'acces aux tableaux et le type d'operande, le type 
destructions utilisees, les strategies de prechargement, les strategies 
d'ordonnancement des instructions et des iterations. 

21. Systeme selon Tune quelconque des revendications 16 a 
10 20, caracterise en ce que les parametres dynamiques (7) comprennent 

notamment la localisation des operandes tableaux dans les differents 
niveaux de la hierarchie memoire, la position relative des adresses de 
depart des tableaux et Itiistorique des branchements. 

22. Systeme selon Tune quelconque des revendications 6, 8 et 
15 9, caracterise en ce que la base des noyaux optimises (16) comprenddes 

sequences de code source de type boucle correspondant a des fragments 
de code reel et utile et organises en niveaux par ordre de complexite 
croissante. ....... 

23. Systeme selon I'une quelconque des revendications 1 a*12 
20 caracterise en ce que la plate-forme materielle predefine (90) comporte .-. 

au moins un processeur du type Itanium. : 

24. Systeme selon I'une quelconque des revendications 1 a'12 
caracterise en ce que la plate-forme materielle predefinie (90) comporte 
au moins un processeur du type Power ou PowerPC. 

25 25 - Systeme selon I'une quelconque des revendications 13 a 15 

et selon la revendication 23, caracterise en ce que les regies d'optimisation 
(9) comprennent au moins certaines des regies suivantes : 

(a) minimiser le nombre d'Ecritures en cas de mauvaise performance des 
Ecritures par rapport aux Lectures, 

30 (b) importance de ('utilisation des paires de chargement en virgule 
flottante, 

(c) ajuster le degre de deroulage en fonction de la complexite du corps 
de boucle, 

(d) utiliser les latences operationnelles des operations arithmetiques, 
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(e) appliquer des techniques de masquage pour les vecteurs courts, 

(f) utiliser des suffixes de localite pour les acces memoire (Lecture, 
Ecriture, Prechargement), 

(g) definir les distances de Prechargement, 

5 (h) effectuer une vectorisation de degre 4 pour eviter une partie des 
conflits de bancs L2 

(i) prendre en compte de multiples variantes pour eviter une autre 
partie des conflits de bancs L2 et les conflits dans la file d'attente des 
Lectures/Ecritures 

10 (j) prendre en compte les gains de performances lies aux differentes 
optimisations. 

(k) utiliser des chaines de branchement minimisant les mauvaises 
predictions (vecteurs courts) 

(I) fusionner les acces memoires (regroupement de pixels) 

15 (m) vectoriser les traitements sur pixels, 

26. Systeme selon Tune quelconque des revendications 13 a 15 
et selon la revendication 24, caracterise en ce que les regies d'optimisation 
(9) comprennent au moins certaines des regies suivantes : 

(a) reordonnancer les Lectures pour regrouper les defeuts de caches 

20 (b) utiliser le prechargement uniquement sur les Ecritures 

(c) ajuster le degre de deroulage en fonction de la complexity du corps 
de boucle, 

(d) utiliser les latences operationnelles des operations arithmetiques, 

(e) utiliser des suffixes de localite pour les acces memoire (Lecture, 
25- Ecriture, Prechargement), 

(f) definir les distances de Prechargement, 

(g) prendre en compte d ■= multiples variantes. pour eviter. las .conflits dans 
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Optimisation et generation de code 
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